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TRAFFIC DEPENDENT BLUETOOTH SCATTERNET OPTIMIZATION 

PROCEDURE 

BACKGROUND 

The present invention relates to ad-hoc networks. More particularly, the 
5 present invention relates to network optimization in ad-hoc networks. 

Conventional networking protocols are based on the characteristics and/or 
features of networks with fixed infrastructures. In networks with fixed 
infrastructures, the arrangement of the links between network nodes typically does 
not change. The disadvantage is that networks with fixed infrastructures cannot be 
10 easily reconfigured to account for increases in data traffic, also called system 
loadmg. Accordmgly, when system loading increases for one node, the 
surrounding nodes are likely to experience increased delays m the transmission and 
reception of data. 

In contrast to networks with fixed infrastructures ad-hoc networks do not 
15 have a fixed infrastructures. Accordingly, nodes in ad-hoc networks act as both 
hosts and routers. An ad-hoc network is formed when a number of nodes decide 
to join together to form a network. Bluetooth is an exemplary ad-hoc networking 
technology. Bluetooth is an open specification for wireless communication of both 
voice and data. It is based on a short-range, universal radio link, and it provides a 
20 mechanism to form small ad-hoc groupings of connected devices, without a fixed 
network infrastructure. Bluetooth devices can include devices such as printers, 
PDAs, desktop computers, FAX machines, keyboards, joysticks, telephones or 
virtually any device. Bluetooth operates in the unlicenced 2.4 GHz Industrial- 
Scientific-Medical (ISM) band. 
25 Figure 1 illustrates a Bluetooth piconet. A piconet is a collection of digital 

devices, such as any of those mentioned above, connected using a single Bluetooth 
frequency hopping channel. A piconet is uutially formed with two connected 
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devices, herein referred to as Bluetooth nodes. A piconet can include up to eight 
active Bluetooth nodes. In each piconet, for example piconet 100, there exists one 
master Bluetooth node and one or more slave Bluetooth nodes. In figure 1 
Bluetooth node 101 is the master node and node 102 is a Bluetooth slave node. 
5 According to the Bluetooth standard a slave node can directly communicate 

only with the master node. However, it is assumed that Bluetooth can be 
implemented such that two slave nodes can communicate through the master node. 
Figure 2 illustrates a piconet with a master node 201 and a plurality of slave nodes 
202-208 arranged in a star network topology. If slave node 202 wishes to 

10 communicate with slave node 206, slave node 202 would have to transmit the 
information it wished to communicate to the master node 201 . Master node 201 
would then transmit the mformation to slave node 206. 

A scatternet is formed by multiple independent and unsynchronized 
piconets. Figure 3 illustrates an exemplary scatternet 300. In figure 3, piconet 1 

15 includes the master node 303 and the slave nodes 301, 302 and 304; piconet 2 
includes the master node 305 and the slave nodes 304, 306 and 307; piconet 3 
mcludes the master node 309 and the slave nodes 308, 310 and 311; and piconet 4 
mcludes master node 310 and slave node 312. As illustrated in figure 3, node 310 
acts as both a slave node m piconet 3 and as the master node of piconet 4. To 

20 implement a scatternet it is necessary to use nodes which are members of more 
than one piconet. Such nodes are herein referred to as bridge nodes. If, for 
example, node 301 wishes to communicate with node 312, then nodes 304, 308 
and 310 act as bridge nodes by bridging the connection between the three piconets 
and in particular between nodes 301 and 312. For example, node 301 transfers 

25 the mfonnation to the master node of piconet 1 node 303. Master node 303 

transmits the information to bridge node 304. Bridge node 304 then forwards tibie 
information to master node 305, which in turn, transmits the information to bridge 
node 308. Bridge node 308 forwards the mformation to master node 309 which 
transmits the information to bridge node 310, which in turn, forwards the 
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information to destiiiation node 312. 

Due to the Bluetooth protocol, a Bluetooth unit can transmit or receive in 
only one piconet at a time. Accordingly, a bridging Bluetooth unit must switch 
between piconets on a time division basis. Since the bridging unit must 
5 synchronize its radio from one piconet to another and perform the necessary 
signaling, the throughput of the piconet is reduced due to the amount of time 
requked to switch between piconets and due to the associated control signaling. 

Altihiough it is assumed that scattemet forming can be performed titirough 
the use of nodes participating in more than one piconet at a time as described 
10 above, the current Bluetooth specification does not define methods for selecting 

which links to setup and how to choose master and slave roles. As a consequence, 
a very large number of scattemet configurations are possible for a given set of 
nodes. While many different scatternets may provide coionectivity for a given set 
of nodes, their performance m terms of achievable throughput and delay are 
15 largely different. This is because different scattemet configurations can differ in 
the number of hops between nodes, the amount of overhead due to bridging 
between piconets, and the actual traffic mix m each piconet. However, there are 
no known methods for using a single scattemet to optunize its own configuration. 

SUMMARY 

20 These and other problems, drawbacks and limitations of conventional 

techniques are overcome according to the present invention by a method and 
apparatus which dynamically reconfigures a network, la accordance with 
exemplary embodiments of the present mvention the methods and apparatus are 
distributed in each node m the network, wherein each node determines based upon 

25 mformation stored in the node whether to initiate reconfiguration of the network. 

In accordance with one aspect of the present invention it is determined 
whether a predetermined time period has expired. If the predetexmined time 
period has expired a table is examined. A Imk setup procedure, a role switch 
procedure or a link teardown procedure based upon information in the first or 
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second table is selectively initiated. The link setup procedure is initiated by a 
node which forwards traffic between two end nodes, and the role switch procedure 
and the link teardown procedure are initiated by an end node. 

In accordance with another aspect of the present inventioxi a network 

5 includes a first node including a first table and a second node including a second 
table. A first conmunications Imk connects the first node and fbie second node. 
The first node and the second node periodically determine whether to initiate 
reconfiguration of the network based upon information stored in the first and 
second tables. The first table contains information about traffic that the first node 

10 is forwarding and information about traffic to and firom nodes which are neighbors 
of the first node, and the second table contains information about traffic that the 
second node is forwarding and information about traffic to and from nodes which 
are neighbors of the second node. 



BRIEF DESCRIPTION OF THE DRAWINGS 
15 The objects and advantages of the invention will be understood by reading 

the foUowhag detailed description m conjunction with the drawings in which: 
FIG. 1 illustrates an exemplary piconet; 
FIG. 2 illustrates an exemplary star-topology network; 
FIG. 3 illustrates an exemplary scattemet formed by a plurality of 
20 piconets; 

FIG. 4 illustrates logical elements in a node in accordance with exemplary 
embodhnents of the present invention; 

FIGs. 5A and 5B respectively illustrate an exemplary Traffic Forwardmg 
Table and an exemplary Neighbor Traffic Table m accordance w^ith the present 
invention; 

FIGs. 6A and 6B illustrate a plurality of nodes which exc^iange messages 
during Link Setup in accordance with the present invention; 

FIG. 7A illustrates an exemplary method for initiating Li:»k Setup m 
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accordance with the present invention; 

FIGs. 7B and 7C illustrates an exemplary method for performing Link 
Setup in accordance with the present invention; 

FIGs. 8A-8C illustrate exemplary messages used for Link Setup in 
5 accordance with the present invention; 

FIGs. 9A and 9B illustrate a plurality of nodes performing a Master-Slave 
Switch in accordance wifli exemplary embodiments of the present invention; 

FIG. 10 illustrates an exemplary method for the initiation of the Master- 
Slave Switch in accordance with the present mvention; 
10 FIG. 11 illustrates an exemplary method for performing the Master-Slave 

Switch in accordance with the present invention; 

FIGs. 12A and 12B illustrate exemplary messages for the Master-Slave 
Switch in accordance with the present invention; 

FIGs. 13A and 13B illustrate a plurality of nodes performing a Link 
15 Teardown in accordance with exemplary embodiments of the present invention; 

FIG. 14 illustrates an exemplary method for the initiation of Link 
Teardown in accordance with the present invention; 

FIG. 15 illustrates an exemplary mefliod for performing Link Teardown in 
accordance with the present invention; 
20 FIGs. 16A and 16B illustrate exemplary messages exchanged during Link 

Teardown in accordance with the present invention; and 

FIGS. 17-19 illustrate a plurality of nodes reconfiguring their connections 
usmg Lmk Setup, Master-Slave Switch and/or Link Teardown im accordance with 
exemplary embodiments of the present invention. 



25 DETAILED DESCRIPTION 

The present invention is directed to optimization of network configuration. 
In general, the present invention accomplishes this by dynamically assigning 
master and slave roles, and by dynamically settmg up and tearing down links 
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between nodes. In so doing, a network topology is dynamically reconfigured 
based upon the current traffic requirements of the network. 

In the following, the present invention is described as a technique for use 
in a Bluetooth scatternet. However, one skilled in the art will recognize that the 
5 present invention is applicable to other types of wireless or wireline networks. 

Figure 4 illustrates the logical elements in each node in accordance with 
die present invention. The logical elements can be broken down into data 
structures, procedures and messages. Each node in the scatternet maintams a 
Traffic Forwarding Table and a Neighbor Traffic Table data structure. As will be 
10 described in more detail below, each node will periodically scan its Neighbor 

Traffic Table and Traffic Forwarding Table. Based on the information contained 
in these tables, the node will decide whether it may be beneficial for it to initiate a 
reconfiguration attempt. Link Setup procedures will be initiated by a node 
forwardmg traffic between two other nodes, while Link Teardown and Lmk 
15 Master-Slave Switch procedures are initiated by one of the end nodes of a 
particular link. 

As indicated by the Imks between the Traffic Forwarding Table data 
structure and the Link Setup procedure in figure 4, the Traffic Forwarding Table 
will be used by a particular node during the Lmk Setup procedure. Furthermore, 

20 as indicated by links between the Link Setup procedure and the LinkSetupSolicit, 
LinkSetupReq and LinkSetupAck messages, these messages are used during the 
Lmk Setup procedure. Moreover, as mdicated by the links between the Neighbor 
Traffic Table data structure and Link Setup, Lmk Master-Slave Switch and Lmk 
Teardown procedures, the Neighbor Traffic Table will be used for these 

25 procedures. As also indicated by the links between the Link M/S switch 

procedure and the Link M/S switch request and LinkMSSwitchAck messages, 
these messages are used durmg the link M/S switch procedure. Fmally , as 
indicated by the link between the LinkTeardown procedure, the LinkTeardownReq 
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and LiBkTeardownAck messages, these messages are used during the 
LinkTeardown procedure. 

Figure 5A illustrates an exemplary Traffic Forwarding Table in accordance 
with the present invention. The Traffic Forwarding Table contains information 
5 regarding data packets that are forwarded by the particular node, i.e, , traffic that 
is neither originated from nor destmed to the particular node. The JSrst column of 
the Traffic Forwardmg Table, "Between", indicates the pair of nodes for which 
the particular node is forwarding the packets. The second column of the table, 
"Traffic", contains a measurement of the amount of traffic that is forwarded by 

10 the particular node for each pair of nodes. The measurement of the amount of 
traffic contamed in the second column of the Traffic Forwarding Table is an 
average measurement over a predetermmed measurement period. The third 
column of the Traffic Forwarding Table, mdicates the time when the last 

Link Setup solicit message was sent, and the fourth column, "Bs^Eup". represents 

15 the backoff counter. B^^^ is a backoff counter used for setting up a link between 
two nodes. 

Figure 5B illustrates the Neighbor Traffic Table. The Neighbor Traffic 
Table contains information regarding the neighbor nodes (both ctirrent and 
previous neighbors) and the amount of traffic to and from each neighbor. The 

20 first column of Neighbor Traffic Table, "To Node", indicates each neighbor of the 
particular node, i.e., nodes that are directly connected by a Bluetooth link. In 
addition, nodes that are not connected to the particular node, but are visible, i.e., 
within radio range of the particular node, or even other nodes that are not within 
radio range of the particular node, can also be mcluded m the Ne?ighbor Traffic 

25 Table. The second column of the Neighbor Traffic Table, "Role " , indicates the 
role of the neighbor node, wherein an M indicates a master node role, an S 
indicates a slave node role, IN or OUT indicates whether the particular node is 
within range or out of radio range, and Unknown indicates that it is unknown 
whether a node is within or without of the radio range of the particular node. The 
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third column of the Neighbor Traffic Table, "Traffic", provides the total 
measured traffic on the given link in both directions. The total measured traffic is 
an average value over a predetermined measurement period. The fourth column 
of the Neighbor Traffic Table, provides the time when this link was 

5 setup. The fifth column, "T^eardown". indicates the time at which the link between 
the particular node and the neighbor node was torn down. The sixth column, 
"Bteardown**. a backoff timer for the tearing down of a link between the particular 
node and the neighbor node. The seventh column, TMSs^i^h, provides a time when 
the last Master-Slave Switch initiations were sent between the particular node and 

10 the neighbor node. The eighth column of the Neighbor Traffic Table, "Bj^sswitch" » 
is a backoff counter for the Master-Slave Switch. 

Figures 6A and 6B illustrate a plurality of nodes which are performing a 
Link Setup in accordance with exemplary embodiments of the present invention. 
The arrows illustrated m figures 6A and 6B indicate regular traffic flow between 

15 the nodes and not necessarily the messages used for the LinkSetap procedures. 

Figure 6A illustrates that initially node A sends traffic which is destmed for node 
B through node C. Node C, the forwarding node, would initiate a LinkSetup 
procedure and solicits nodes A and B to setup a direct link between the two nodes. 
Accordmgly, as illustrated in Figure 6B, after the link between nodes A and B are 

20 setup, nodes A and B can directly exchange mformation between, the two nodes 
without sending the mformation through node C. Further, as illustrated by the 
half-light, half-dark circle of node A, node A now is the master node of the 
piconet comprising nodes A and B and a slave node in the piconet comprising 
nodes A, B and C. 

25 Figure 7A illustrates an exemplary method for determininig whether a node 

should mitiate a Link Setup procedure. Link reconfiguration initiation decisions 
are made periodically at each node at the expiration of a time period of T^heck- 
This time period will not be equal at all nodes, but instead it will be chosen 
randomly between Teheckmin and T^u^^. The difference between Teheckmia 
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Tcheoteiax detennines the amount of randomization that will be allowed when 
selecting Ta^. It will be recognized that increasing the values of Tchecknun 
Tcheckmax decTcases the amount of computational and communications overhead 
imposed on nodes and improves the accuracy of traffic measurements and 
5 therefore makes reconfiguration attempt decisions more accurate. However, 

increasing these values may slow down the reconfiguration process. Accordiagly, 
once a node, e.g., node C, determines whether the time period Tcheck e:q>ired, 
the node determines whether to initiate a Link Setup procedure based upon the 
information stored in the Traffic Forwarding Table. Using the Traffic 

10 Forwarding Table, node C examines each row to determine whether the traffic for 
that row is less than Traff^„,etup- Traff^^^mp is the minimum amount of forwarded 
traffic that triggers Link Setup. For each row where traffic is less than Traf^ 
^ node C sets the backoff counter, B^p equal to 1 (Step 703). Node C then 
selects all nodes m the Traffic Forwarding Table which have not had a Link Setup 

15 initiation for at least V,,^^ * B,,^p (Step 706). P,etup is a time period which is half 
the minimum time period between two Link Setup initiation atternpts. Next node 
C determines whether at least one node was selected from the Traffic Forwarding 
Table (Step 709). If no nodes were selected from the Traffic Fojrwarding Table 
("No" path out of decision Step 709), then the processing for node C ends (Step 

20 712). 

If at least one node from the Traffic Forwarding Table w^s selected ("Yes" 
path out of decision Step 709), then node C selects the row R wi«h the highest 
traffic m the Traffic Forwarding Table out of the selected nodes (Step 715). Next 
node C determines whedier the traffic in the row R is less than Ti^niBsecap (St^ 
25 718). If node C determines that the traffic in the selected row is less than 

Trafi^„,etup ("Yes" path out of decision Step 718) then the processing for the node 
ends (Step 712). If, however, die traffic in tiie selected row is n«ot less than 
Traff^etup ("No" path out of decision Step 718) then node C up(^ates T^etup to the 
current tune t (721). Next node C sets the backoff counter to a mimmum 
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value of 2*B3,t„p and B^^^p^ (Step 724) and sends a LinkSetupSoUcit message to 
any of the nodes between which traffic in the selected row R is forwarded (Step 
727). The backoff timer B^etup is set to 2*6,,^,^ to reduce the frequency that a node 
initiates a Link Setup, while setting an upper limit of 6^^^^^^^^ prevents the backoff 
5 timer from mcreasing to a very high value where Link Setup is initiated too 
infrequently. 

Figure 7B illustrates an exemplary method for a node which has received a 
LinkSetupSolicit message. Initially, a node, e.g., node A, receives a 
LinkSetupSoUcit message from C (Step 730). Figure 8A illustrates the 

10 LinkSetupSolicit message which includes a From field, a To field, a Between field 
and a WinNet field. The From field indicates the node which is sending the 
LinkSetupSolicit message, the To field indicates the node which is to receive the 
LinkSetupSolicit message, the Between field indicates tibie two end pomts of the 
new Imk and the WinNet field indicates the amount of capacity i» kilobits per 

15 second (kbps) that is expected to be freed at the forwarding noda as a result of 
rerouting the forwarded traffic to the new link. 

Node A then determines whether a time period of at least Pdown passed 
since the last Imk was torn down (Step 733). The time period P^own is a constant 
value and is selected such that nodes which have recently been setup are not torn 

20 down. It will be recognized that increasing the value of P^own slows the 

reconfiguration process but decreases the risk of unnecessarily setting up a new 
link that will be torn down soon afterwards. If the node determiii^s that P^j^^u has 
not passed ("No" path out of decision Step 733) then the Link S^tup procedure 
fails (Step 736). If, however, the thne period P^^^ has passed (''Yes" path out of 

25 decision Step 710) then node A determines the amount of capacHy increase 

WiiiMaster(A) and WinSlave(A) if the requested link were built (Step 739). It 
will be recognized that the increase in capacity is equal to the ne^gative of the 
increase in the overhead. If both WinNet + WinSlave(A) and WinNet + 
Wu3Master(A) are less than zero ("Yes" path out of decision Ste^p 742) then the 
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procedure fails (Step 736). If WinNet + WmSlave(A) and WinNet + 
Wij]Master(A) are not both less than zero ("No" path out of decision Step 742) 
then node A sends a LinkSetupReq message to the other end of the link including 
WinMaster(A) and WinSlave(A) (Step 745). 
5 Figure 8B illustrates the LinkSetupReq message which includes a From 

field, a To field, a Traff field, an M/S field, a WinNet field, a WmMaster field 
and a WinSlave field. The From field mdicates the node which is sending the 
LuikSetiipReq message, the To field indicates the link which is to receive the 
LinkSetupReq message and the Traff field is the amount of current traffic activity 

10 for the source node including both incoming and outgoing traffic. The M/S field 
indicates whether the node which is sending the LinkSetupReq message is a master 
or not, the WinNet field is the amoimt of capacity that the forwarding node is 
expected to gain as a result of setting up the Imk, the WmMaster field and the 
WinSlave field are the amount of capacity that the source is expected to gain as a 

15 result of setting up the link when the source node acts as the master or a slave 
node, respectively. Accordingly, in the example described above in connection 
with figure 7B, node A would place WmMaster(A) in the WinMaster field and 
WinSlave(A) in the WinSlave field. 

Figure 7C illustrates an exenq)lary method for a node which receives a 

20 LinkSetupReq message. A node, e.g., node B, receives the LmkSetapReq 

message (Step 748) and calculates WinMaster(B) and WinvSlave(B) (Step 751). 
Next node B calculates gain M, which is equal to WinNet + WinMaster(B) + 
WinSlave(A) and gain S, which is equal to WmNet + WinMastefr(A) + 
WinSlave(B) (Step 754). If gam M and gain S are bodi greater than 0 ("Yes" path 

25 out of decision step 757) then node B selects die larger of the gains between gain 
M and gain S and sends a LuikSetupAck message to node A (Step 760). If gain M 
is larger than Gain S then node B acts as the master node and if Gain S is larger 
than Gain M node B acts as a slave node. 

Figure 8C illustrates the LmkSetupAck message which uicludes a From 
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field, a To field, an M/S field and an Mo field. The From field indicates tbe 
node which is sending the Link Setup acknowledge message, the To field indicates 
the destmation of the Link Setup acknowledge message, the M/S field indicates 
whether the node which is sending the Lmk Setup acknowledge message will 
5 become the master or slave of the new link and the Info field can contain 

additional information which may be used in the actual Link Setup process, e.g. , 
page timing information. 

If gain M and gain S are not both greater than 0 ("No" path out of decision 
step 757) then node B determines whether gain M is greater than 0 (Step 763). If 

10 gain M is greater than 0 ("Yes" path out of decision step 763) then node B sends 
accepts the setup request with node B acting as the master node by sending a 
LinkSetupAck message (Step 766). If the gain M is not greater than zero ("No" 
path out of decision step 763) node B determines whether the gain S is greater 
than zero (Step 769). If the gam S is greater than zero ("Yes" path out of decision 

15 Step 769) then node B accepts the setup request with node B acting as a slave node 
by sendmg a LinkSetupAck message (Step 772). If, however, the gain S is not 
greater than zero ("No" path out of decision Step 769) then node B will refuse the 
request (Step 775). Node B refuses the request by not responduig to node A with 
an acknowledgment message. Accordingly, the load on the network will not be 

20 increased when requests to setup Imks are refused. 

The procedure described above in comiection with figure 7A-7C begins 
with the solicitation of a new link between the two nodes that create the highest 
amount of forwarded traffic. If this procedure is successful, the traffic 
measurement will drop below the threshold Traff^ setup before the new check 

25 2*Psetup time later. In addition, an exponential backoff scheme is used for sendmg 
solicitation messages in order to avoid a high load of these control messages. The 
exponential backoff scheme is implemented such that the backoff counter is 
multiplied by two each Link Setup attempt, and hence, unsuccessful Link Setup 
attempts are repeated with half the frequency of the previous Link Setup attempt. 
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Further, although the procedure descaribed above in connection with figure 7 
illustrates selectmg the larger of the Gain M and Gain S, the procedure can also be 
implemented where if one of the nodes is already the master and the other node is 
not then the master node will also be the master of the new link. If neither of the 
5 nodes is the master or both of them are, then the node witii the highest traffic 
activity will be the master of the new Mnk. 

Figures 9 A and 9B illustrate a plurality of nodes before and after a Master- 
Slave Switch. The arrows illustrated in figures 9A and 9B indicate regular traffic 
flow between the nodes and not necessarily the messages used for the Master- 

10 Slave Switch procedures. Accordingly, as illustrated in Figure 9A, node A is the 
master of die plconet comprising nodes A and B, and node A is a slave in the 
piconet comprising nodes A, B and C. Since node A is exchanging information 
with node B and since node A is both the master of one piconet and a slave of 
another piconet, node A must divide its time between the piconet comprismg 

15 nodes A and Band the piconet comprising nodes A, Band C. A^ccordingly, node 

< 

A determines that it is more beneficial for it to play the master role in the link 
between nodes A and B. As illustrated in Figure 9B, after the Iv^aster-Slave 
Switch is performed between nodes A and C, node A has now become the master 
of the piconet comprising nodes A, B and C. Further, node C is a slave in the 

20 piconet comprising nodes A and C and the master of the piconet comprising nodes 
B and C. By playiug the master role in both links node A can ii».crease its 
throughput of information being transmitted to node B because n-ode A does not 
have to switch to participate in the piconet comprising nodes A, ^ and C. 

Figure 10 illustrates an exenplaiy method for mitiating * Master-Slave 

25 Switch. As discussed above, Master-Slave Switches are only initiated by end 
nodes, i.e., either a source or destination node, and are based upon mformation 
contained in one of the end node's Neighbor Traffic Table. If, etJ^ end node, e.g., 
node A, determmes that a time period T^h^^k has expired the node? tihen determines 
whether it is a member of only one piconet (Step 1010). If node A is a member of 
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only one piconet ("Yes" path out of decision Step 1010) then the Master-Slave 
Switch procedure for node A ends (Step 1020). If, however, node A is a member 
of more than one piconet ("No" path out of decision Step 1010) then node A 
selects all nodes in the Neighbor Traffic Table which have not had a Lmk Setup 
5 initiation attempt for at least the time period of PMsswitch 

* BMssw.cn (Step 1025). 
PMsswitch ^ tlie minimum tune period between Master-Slave Switch initiation 
attempts. 

Next, node A determmes whether at least one node was selected (Stesp 
1030). If no nodes were selected ("No" path out of decision step 1030) then 

10 processing for node A ends (Step 1020). If, however, at least one node was 

selected ("Yes" path out of decision step 1030) then node A selects the row R with 
the highest traffic iu the neighbor traffic table out of the selected nodes (Step 
1035). Next, node A determines whether the traffic m the row R is equal to zero 
(Step 1040). If the traffic in the row R is equal to zero ("Yes" path out of 

15 decision Step 1040) then the Master-Slave Switch procedure ends for node A (Step 
1020). 

If the traffic m the row R is not equal to zero ("No" path oat of decision 
Step 1040) then node A updates T^sswrn to the current tune t (Step 1050) and sets 
the backoff timer BMsswad, equal to a minimum value of 2*BMsswitc» BMsswitchmax 

20 (Step 1060) . The backoff timer Bmsswuci, is set to 2*BMsswitch to reduce the 

frequency that a node initiates a Master-Slave Switch, while an upper limit of 
BMsswitchnuK prevents the backoff timer from increasing to a very high value where a 
Master-Steve Switch is mitiated too infrequently. Next node A sends a 
LinkMSSwitchReq message to node B (Step 1070). Figure 12A illusttates a 

25 LmkMSSwitchReq message. The lmk MS switch request messagre mcludes a 
From field, a To field, a Traff field, an M/S field and a Win fielc* • The From 
field mdicates the source of the LmkMSSwitchReq message, the 'J'o field indicates 
the destination node of the LmkMSSwitchReq message, the TrafT field indicates 
the amount of traffic activity on the source node, the M/S field in-dicates whether 
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fhe source node is a master node and the Win field is the amount of capacity that 
the source node expects to gain as a result of a Master-Slave Switch. 

Figure 1 1 illustrates an extmpisay method for a node which receives a 
LinlMSSwitchReq message. Initially, node B receives the LinkMSSwitchReq 
5 message (Step 1130) and calculates Win(B) (Step 1 140). Node B then determines 
whether Win(A) + Win(B) is greater than or equal to zero (Step 1150). If node B 
determines that Win(A) + Win(B) is not greater than or equal to zero ("No" path 
out of decision Step 1150) then node B will refuse the switch (Step 1 160). To 
refuse the switch node B does not do anything, i.e., node B does not send a 

10 message to node A indicating that node B is refusing the switch. By not sending a 
message, the load on the network will not be increased by sending messages for 
refusing Link Master-Slave Switch request. If node B determines that WiQ(A) -f- 
WinCB) is greater than or equal to zero ("Yes" path out of decision Step 1150) 
then node B determines whether Win(A) + Win(B) is equal to zero (Step 1170). 

15 If it is determmed that Wui(A) + Win(B) is not equal to zero ("No" path out of 
decision Step 1170) then node B performs the Master-Slave Switch and sends a 
LinkMSSwitchAck message to node A (Step 1180). 

Figure 12B illustrates a LinkMSSwitchAck message. Hie 
LinkMSSwitchAck message includes a From field, a To field and an Mo field. 

20 The From field mdicates the source node of the LmkMSSwitchAck message, the 
To field mdicates the destination node of the LinkMSSwitchAck message and the 
Info field can contain optional additional information, e.g., timing information, 
used for performing the Master-Slave Switch. 

If it is determined that Win(A) + Win(B) is equal to zero ("Yes" path out 

25 of decision Step 1 170) then node B determines wh^er node A has a higher traffic 
activity than node B (Step 1190). If node B determines that node A has a higgler 
traffic activity than node B ("Yes" path out of decision Step 1190) then node B 
and node A will perform the Master-Slave Switch and node B will send a 
LinkMSSwitchAck message to node A (Step 1 180). If, however, node B 
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determines that node A does not have a higher traffic activity ("No" path out of 
decision Step 1190) then node B refuses the Master-Slave Switch (Step 1160). 

Figures 13A and 13B illustrate a plurality of nodes before and after the 
Link Teardown procedure has been performed. The arrows illustrated in figures 
5 13A and 13B indicate regular traffic flow of messages between tlie nodes and not 
necessarily the messages used for the Link Teardown procedures- As illustrated 
in Figure 13A, node A is the master of the piconet comprising nodes A, B and C, 
and node C is the master of a piconet comprising nodes C and B, As illustrated in 
Figure 13B, it is determined that the link between nodes B and C should be torn 
10 down. Accordingly, the link between nodes B and C is torn dov^ as illustrated in 
Figure 13B. 

Figure 14 illustrates an exemplary method for determining whether to 
initiate a Link Teardown procedure in accordance with the pxesotA invention. 
Link Teardown procedures are initiated by an end node based upon mformation in 

15 the Neighbor Traffic Table. After determiuing that a time period of T^^^^^k 

expired, the node performing the Link Teardown mitiation procedure, e.g. , node 
A, computes an estimated capacity increase (Win) and network capacity decrease 
(WinNet) for each link if torn down (Step 1410), wherem WmN^t=-2*Traf and 
Traf is the traffic on the Link. Next node A selects the rows in the Neighbor 

20 Traffic Table which have Imks which are up for at least P^p and y^l^ch have not 

had a Link Teardown initiation attempt for at least Pg^tup * Bje^rdow^ ^^*^P l^^l^^* ^up 
is the minimum time period before a link may be torn down after the link has been 
setup. Next node A determines whether at least one row was selected (Step 
1420). If no row was selected ("No" path out of decision Step 1^20) the 

25 processing for node A ends (step 1425). If at least one row was selected ("Yes" 
path out of decision Step 1420) then node A selects the row R wi-ih the highest 
value of Win+WinNet out of the selected rows (Step 1430) and cdetermines 
whether the value of Wia+ WinNet is less than zero (step 1440). If it is 
determined that the value of Win + WinNet is less than zero (" Y^es" path out of 
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decision Step 1440) tben the processing for node A ends (Step 1425). 

If node A determines that the value of Win + WinNet is not less than zero 
("No" path out of decision Step 1440) then the node updates 1^,^ to the current 
time t (Step 1450) and sets the backoff timer B,eardown to a minimuin of 2*B,earfowii 
5 and B^^,^^^^ (Step 1460). The backoff timer B,,,^^^ is set to 2*Beeariown to reduce 
the frequency that a node initiates a Link Teardown, while an upper limit of 
Bteardowmaax preveuts the backoff timer from increasing to a very high value where a 
Lmk Teardown is initiated too infrequeatly. Next node A calculates Win(A) (Step 
1465) and sends a LinkTeardownReq message to the node with which it wishes to 
teardown the link (Step 1470). 

Figure 16A illustrates an exemplary LinkTeardownReq message in 
accordance with the present invention. The LinkTeardownReq message includes a 
From field, a To field, a Traff field, a Win field and a WinNet field. The From 
field indicates the node sending the LinkTeardownReq message, the To field 
indicates flie destination of the LinkTeardownReq message and tfje Traff field 
indicates the traffic activity at the source node. The Win field contains an 
indication of the amount of capacity that the source node is expected to gain as a 
result of the Lmk Teardown and the WmNet field is the estimate^i negative gain in 
network capacity as a result of the Link Teardown, Le., WinNet in this case 
represents the increase in overhead due to the Link Teardown. 

Figure 15 illustrates an exemplary Link Teardown proceJ-ure m accordance 
with the present invention. Initially, node B receives the LiokTesardownReq 
message (Step 1530) and calculates Win (B) and WinNet (Step 1540). Node B 
then determmes whether Wm(A) + Win(B) + WinNet is greater than or equal to 
zero (Step 1550). If node B determines that Win (A) + Win (B) + WinNet is not 
greater than or equal to zero ("No" path out of decision Step 1550) then node B 
refuses the LinkTeardownReq (Step 1560). In accordance with esxemplary 
embodiments of the present invention, node B refuses the LinkTeardownReq by 
not doing anything, i.e., the node B does not send a message to dode A indicating 
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that node B is refusing the request. By not sending a message, the load on the 
network will not be increased by sending messages for refusing a Link Teardown 
request. If, however, node B determines that Win (A) + Win (B) + WinNet is 
greater than or equal to zero ("Yes" palh out of decision Step 1550) then node B 
5 accepts the LmkTeardownReq and sends a LinkTeardownAck message to node A 
(Step 1570), 

Figure 16B illustrates an exemplary LinkTeardownAck message in 
accordance with the present invention. The LinkTeardownAck message includes a 
From field indicating the source of the LinkTeardownAck, a To field indicatmg 

10 the destination of the LinkTeardownAck message and an Info field containing 
optional information, e.g., timing information. 

In accordance with the present invention, the sending of the 
LinkTeardownAck message triggers route maintenance procedures of the routing 
protocol such that the dhrect link between the source and destination nodes, i.e., 

15 the link To and From nodes, will be marked as unavailable. If the routing 

protocol finds an alternative path the LinkTeardownAck message can be sent on 
this alternative path. Otherwise, if the routing protocol fails to find an alternative 
path an error will result. In this case the LinkTeardownAck message is dropped 
and the link is logically restored as available to the network. If, however, an 

20 alternative path is found, when the LinkTeardownAck message arrives on the 
alternative path to the other end the link may be torndown. 

To avoid the link being logically marked as unavailable and then restored 
because of a dropped LinkTeardownAck message, the originator of the 
LuikTeardownReq message may trigger an alternative path discovery procedure 

25 before sending the message. Such a procedure may be part of the routhig 

protocol, or it can be unplemented as an addition to the routing protocol. As a 
result of the alternative path discovery, the node will not send the request when 
such an alternative path is not available. When such an alternative path is 
available, it can be possible to determine the length of the alternative path. 



wo 02/25879 



pCT/SEOl/01681 



-19- 

HopCount. By sending the LinkTeardownReq message only when an alternative 
path has been found avoids the other end node unnecessarily marking the link as 
unavailable causing temporary disruptions on the traffic flowing on the link. 
Further, knowledge of the alternative path can be used to estimate the load on the 
5 network that will be caused by tearing the link down, i.e. , WinN^t- Using the 
HopCount, WinNet can be estimated using the formula WinNet^-2*(HopCount- 
l)*Tr, wherein Tr is the traffic on the link. 

If two or more Link. Teardown attempts are being perfonn^d 
simultaneously, one Link Teardown procedure may teardown a link being used by 
10 odier Link Teardown procedures. To avoid two or more Link Teardown attempts 
being performed simultaneously and periodically that would block alternative 
paths to each other, Link Teardown initiation should be performed at randomized 
time instants. 

In accordance with exemplary embodiments of the present invention, since 
15 the Link Setup procedure uses a different table than the Link Te^down and the 
Master-Slave Switch procedures, the Link Setup procedure can performed in 
parallel with die Link Teardown and the Master-Slave Switch procedures. 
Alternatively, Link Setup procedures can be performed serially N?vith the Link 
Teardown and the Master-Slave Switch procedures. In addition-, present 
20 invention may be implemented such that a node initially determiJies whether a link 
can be tomdown and if the Link Teardown procedures are unsuccessful then the 
node would initiate the Master-Slave Switch procedures. 

Now that the exemplary procedures of the present invention have been 
described, several examples will be presented to further illustrate the advantages 
25 of the present invention. Figures 17A through 17F illustrate a {plurality of nodes 
where a node which is an application server is not the master of ^® piconet. The 
arrows illustrated in figures 17A through 17F indicate regular tr-^fSc flow between 
the nodes and not necessarily the messages used for the network reconfiguration 
procedures. Accordingly, Figure 17A illustrates nodes A, B, C D, where 
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node C is the master of the piconet while node A is an application server. Since 
node A is an application server, the nodes of the piconet, i.e. , nodes B through D, 
will be requesting information from node A. However, since node C is the master 
of the piconet, all traffic from node A to nodes B and D must pass through node 
5 C. This results in an inefficient throughput of the piconet. By measuring the 
amount of traffic it is forwarding node C recognizes that the throughput of the 
piconet is inefficient and sends a LinkSetupSolicit message to node A. Node A 
then sends a LinkSetupReq message through node C to node B and node B 
acknowledges the setup of a link between nodes A and B by sending a 

10 LinkSetupAck message to node A through node C. Accordingly ? a new link is 
setup between nodes A and B as illustrated in Figure 17B. 

Figure 17B illustrates the teardown of a link between nodes B and C. 
Initially, node B will send a LinkTeardownReq to node C requesting the teardown 
of the B-C link. In response, node C sends a LinkTeardownAck: message 

15 acknowledging the teardown of the link between nodes B and Hence, the link 
between nodes B and C is torn down. 

Figure 17C illustrates a Link Setup between nodes A and D- The Link 
Setup is initiated by node Csendmg a LinkSetupSolicit message to node A. Node 
A responds with a LinfcSetupReq message which is sent through node C to node 

20 D. Node D accepting the Link Setup sends a LinkSetupAck message through 
node C to node A acknowledging the setup of a link between no^es A and D. 

Figure 17D illustrates the teardown of the link between erodes C and 
Initially, node D sends a LinkTeardownReq message to node C rrequesting to 
teardown the C-D link. Node C accepts the Link Teardown ancL sends a 

25 LmkTeardownAck message to node D acknowledging the teardown of the C-D 
link. 

Figure 17E illustrates the LinkMSSwitch between nodes A and C. As 
illustrated m Figure 17E, node A is a slave of the piconet comprr ising nodes A and 
C, and node A is the master of the piconet comprising nodes A, B and D. 
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Accordingly, node A sends node C a LinkMSSwitehReq message requesting to 
switch the master and slave roles between the two nodes. Node C aclmowledges 
the Master-^lave Switch by sending a LinkMSSwitchAck message back to node A. 
Figure 17F illustrates the network after it has been optimized by the above- 
5 described procedure. Node A which is an application server is now the master of 
the piconet comprising nodes A, B, C and D. Accordingly, the throughput of this 
piconet has now been inoreased by allowing an application server to be the master 
of a piconet in which the nodes which are using the applications are slaves. 

Figures 18A through 18D illustrate another example of a plurality of nodes 

10 which switch from an inefficient network into a more efficient network using 

exemplary procedures of the present invention. The arrows illustrated in figures 
18A through 18D mdicate regular traffic flow between the nodes and not 
necessarily the messages used for the network reconfiguration procedures. In 
Figures 18A through 18D node A is an application server with aodes B through D 

15 as clients of the application server. As illustrated in Figure ISA , node A, an 

application server, is a slave m a piconet comprising nodes A and B; a slave in a 
piconet comprismg nodes A and C; and a slave in a piconet comprising nodes A 
and D. Since an application server, node A, is a slave in three piconets, the 
network is very mefficient due to the overhead of node A switching from one 

20 piconet to another. Recognizmg this situation, node A sends a LinkMSSwitchReq 
message to node C requesting that node A become the master of the piconet 
comprising nodes A and C. Node C accepts the Master-Slave Switch and sends a 
LinkMSSwitchAck message back to node A. 

Figure 18B illustrates that node A is now the master of tbe piconet 

25 comprising nodes A and C and a slave of the piconet comprising nodes A and B 
and the piconet comprises nodes A and D. Accordingly, node A- sends a 
LinkMSSwitchReq message to node D requesting that node A become the master 
of the piconet comprising nodes A and D. Acceptmg the Master-Slave Switch, 
node D sends a LinkMSSwitchAck message back to node A. 
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Figure 18C illustrates that node A is now the master of the piconets 
comprising nodes A, C and D, and the master of the piconet cotaptisiag nodes A 
and D, and a slave in the piconet comprising nodes A and B. Node A initiates a 
Master-Slave Switch by sending a LinJcMSSwitchReq message to node B. Node B 
5 accepts the Master-Slave Switch and sends a LinkMSSwitchAck message back to 
node A. Accordingly, as illustrated in Figure 18D, an application server, node A, 
is the master of the piconet including nodes B through D, which results in a more 
efficient network configuration. 

Figures 19A through 191 illustrate a plurality of nodes which are initially 

10 connected as a string and eventually connected in a star configuration. The 

arrows illustrated in figures 19A through 191 indicate regular traffic flow between 
the nodes and not necessarily the messages used for the network reconfiguration 
procedures. Further, node A is an application server sending information to 
nodes B through F which act as clients. In Figure 19A, node B is the master of a 

15 piconet comprising nodes A, B and C; node D is the master of ttic piconet 

comprising nodes C, D and E; and node F is the master of a piconet comprising 
nodes F and E. Based upon the configuration illustrated in Figure 19A, node B 
requests that a link be setup between nodes A and C, node C req.-«ests that a link 
be setup between nodes B and D, and node E requests that a link: be setup between 

20 nodes D and F. 

Figure 19B illustrates the results of the various Link Setirps described in 
connection with Figure 19A. Accordingly, node B is the master of a piconet 
comprising nodes A, B, C and D; node C is the master of a pico:*iet comprising 
nodes C and A; node D is the master of a piconet comprising no^es C, D, E and 

25 F; and node F is the master of a piconet comprising nodes E and- F. Based upon 
the configuration iUustrated in Figure 19B, C performs a Link T^ardown with 
node B, D performs a Link Teardown with node B, and node E performs a Luik 
Teardown with node F. 

Figure 19C illustrates the results of the various Link Tea^downs described 
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above in comection with Figure 19B, As illustrated in Figure 19C, node B is the 
master of a piconet comprising nodes A and B; node C is the master of a piconet 
comprising nodes A and C; and node D is the master of a piconet comprising 
nodes D, C, E and F. Based upon the configuration illustrated in Figure 19C, 
5 node C performs a Master-Slave Switch with node D and node A performs a 
Master-Slave Switch with node B. 

Figure 19D illustrates the results of the Master-Slave Switches described 
above in connection with Figure 19C. As illustrated in Figure 19D, node A is the 
master of a piconet comprising nodes A and B; node C is the master of a piconet 

10 comprising nodes A, C and D; and node D is the master of a piconet comprising 
nodes D, E and F. Based upon the configuration illustrated in Figure 19D, node 
C initiates a Link Setup procedure between nodes A and D and node D initiates a 
Link Setup procedure between nodes C and F. 

Figure 19E illustrates the result of the above-described Link Setup 

15 procedures. As illustrated in Figure 19E, node A is the master of a piconet 

comprising nodes A, B and D; node C is the master of a piconet comprising nodes 
A, C, D and F; and node D is the master of a piconet comprising nodes D, E and 
F. Based upon the configuration illustrated in Figure 19E, node D performs a 
Lmk Teardown procedure with node C and node F performs a Link Teardown 

20 procedure with node D, 

Figure 19F illustrates the results of the Link Teardown procedures 
described above in connection with Figure 19E. In Figure 19F, node A is the 
master of a piconet comprising nodes A, B and D; node C is the master of a 
piconet comprising nodes A, C and F; and node D is the master of a piconet with 

25 node E. Based upon the configuration illustrated m Figure 19F, node A initiates a 
Master-Slave Switch with node C. 

Figure 19G illustrates the results of the Master-Slave Switch between 
nodes A and C described above in connection with Figure 19F. As illustrated in 
Figure 19G, node A is the master of a piconet comprising nodes A, B, C and D; 
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node C is the master of a piconet comprising nodes C and F; and node D is the 
master of a piconet comprising nodes D and E. Based upon the configuration 
illustrated in Figure 19G, node C initiates a Link Setup procedure between nodes 
A and F and node D initiates a Link Setup procedure between nodes A and E. 
5 Figure 19H illustrates the results of the Link Setup procedures described 

above in connection with Figure 19G. As illustrated in Figure 19H, node A is the 
master of a piconet includiug nodes A, B, C, D, E and F; node C is the master of 
a piconet comprising nodes C and F; and node D is the master of a piconet 
comprising nodes D and E. Based upon the configuration illustrated in Figure 

10 19H, node F initiates a Link Teardown procedure with node C and node D 
initiates a Link Teardown procedure with node E. 

Figure 191 illustrates the result of the Link Teardown procedures described 
above in Figure 19H. As illustrated in Figure 191, node A, which is an 
application server, is now the master of a piconet comprising nodes A through F. 

15 Accordingly, nodes B through F can now directly request and access information 
stored on the application server A without having to send the request or receive 
the information through other nodes. 

It will be recognized that in certain situations using the above-described 
network reconfiguration procedures may not result in the most efficient 

20 configuration of the network being formed because an intermediate configuration 
results in worse performance than the original configuration. For example, 
referrmg now to figures 20A-20C, assume that the network configuration of 20C 
is more efficient than the network configurations of figures 20 A and 20B. Further 
assume that the network configuration of figure 20A is more eflEicient than the 

25 network configuration of figure 20B. Since the network configuration illustrated 
in figure 20A is more efficient than the network configuration in figure 20B, the 
nodes will not perfonn a reconfiguration to the network configuration in figure 
20B, and hence, the more efficient network configuration of figure 20C will not 
be formed. In other words, since figure 20B has more links, the nodes may 
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iaterpret this as resulting in higher overhead. To address this situation, the 
requirements for Link Setup conditions can be loosened. For example, more 
optimistic, i.e., smaller, values for the overhead of establishing a new link when 
computing the Win values in the Link Setup procedure can be used. If the smaller 
5 values of the overhead for establishing a new link are used a longer interval for 
Pjh,^ should be used to avoid instability which would result from setting up a new 
link that has been recently torn down. 

Although the present invention has been described using a constant time 
period for a node to initiate reconfiguration attempts, a node could set the time 

10 between sending two reconfiguration attempt messages based on the amount of 
traffic that would be affected by the reconfiguration. Accordingly, a 
reconfiguration which affects a lot of traffic will likely be performed earlier than 
another reconfiguration which affects less traffic. Adjusting the time between 
reconfiguration attempts can be useful when a number of nodes perform 

15 reconfiguration attempts simultaneously and these reconfiguration attempts 

exclude each other. For example, if two nodes independently initiate a new Link 
Setup, where one of the node is forwarding 50kbps of information and the other 
node is forwarding 200kbps of information. When the two Link Setups exclude 
each other, i.e., one of the Link Setup will not be performed as soon as the other 

20 Luik Setup is performed, then it is beneficial if the one forwarding the less amount 
of traffic waits a longer time before initiation than the other. In this way it is 
more likely that a reconfiguration that affects more traffic will be the one to be 
carried out. 

Although in the procedures above, a reconfiguration attempt would not be 
25 performed if the expected capacity change is negative, i.e., there will be less 
capacity after the reconfiguration than before, in certain situationis it may be 
advantageous to allow these reconfiguration to occur. For example, by taking into 
account the amount of free capacity that a node has, a node which has a large 
amount of free resources can accept a reconfiguration attempt which implies a 
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higher amount of overhead because this does not reduce the network capacity if 
more overhead is imposed on nodes that have free capacity. Further, network 
capacity can be improved if a reconfiguration decreases the overhead at 
overloaded nodes even at the cost of imposing more overhead on nodes with free 
5 capacity. 

Further, although the present invention has been described as using two 
separate tables, i.e., a Traffic Forwarding Table and a Neighbor Traffic Table, to 
make reconfiguration decisions, it will be recognized that these tables can be 
combined into one table. 

10 The present invention has been described with reference to several 

exemplary embodiments. However, it will be readily apparent to those skilled in 
the art that it is possible to embody the invention in specific fornos other than those 
of the exemplary embodiments described above. This may be done without 
departing from the spirit of the invention. These exemplary embodiments are 

15 merely illustrative and should not be considered restrictive in any way. The scope 
of the invention is given by the appended claims, rather than the preceding 
description, and all variations and equivalents which fall within the range of the 
claims are intended to be embraced therein. 



wo 02/25879 



PCT/SEOl/01681 



-27- 

WHAT IS CLAIMED IS: 

L In an ad-hoc network a method for reconfiguring the network 
comprising the steps of: 

determining whether a predetermined time period has expired; 
5 examining a table if the predetermined time period has expired; and 

selectively initiating a link setup procedure, a role switch procedm-e or a 
link teardown procedure based upon information in the first or second table, 

wherein the link setup procedure is kdtiated by a node which forwards 
traffic between two end nodes, and the role switch procedure and the link. 
10 teardown procedure are initiated by an end node. 

2. The method of claim 1 , wherem the first table contains information 
about traffic that a node is forwarding and the second table contains information 
about traffic of neighboring nodes. 

3. The method of claim 1, wherein the link setup procedure comprises 
15 the steps of: 

sending a link setup solicit message to a first end node; 
sending a link setup request message from the first end node to a second 
end node; and 

responding with a link setup acknowledgment message from the second 
20 end node if the second end node accepts the link setup. 

4. The method of claun 3, wherem the second node accepts the hnk 
setup based upon whether the link to be setup increases the capacity of the 
network. 



5. The method of clahn 1 , wherem the Imk role switch procedure 
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comprises the steps of: 

sending a link role switch request message from a first end node to a 
second end node; and 

responding with a link role switch acknowledgment message from the 
5 second node to the first node if the second node accepts the role switch. 

6. The method of claim 5, wherein the second node accepts the role 
switch if the role switch increases the network capacity or if the network capacity 
is unchanged by the role switch, the second node accepts the role switch if the 
first node has a higher traffic activity than the second node. 

10 7. The method of clahn 1, wherem the link teardown procedure 

comprises the steps of: 

sending a link teardown request message from a first node to a second 
node; and 

responding with a link teardown acknowledgment message from the second 
15 node to the first node if the second node accepts the link teardown request. 

8. The method of claim 7, wherem the second node accepts the Imk 
teardown request based upon the sum of capacity increase at the &st and second 
nodes as well as a capacity change in the network due to rerouting of traffic from 
the torn down link. 

20 9. The method of claim 1 , wherem the network operates m accordance 

with Bluetooth protocol. 

10. The method of claim 1 , wherem the network is a wireless network. 



11. The method of claim 7, wherem the link teardown procedure 
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further comprise the steps of: 

triggering a route maintenance procedure to find an alternative path 
between the first node and the second node; and 

sending the link teardown acknowledgment message over the alternative 

5 path. 

12. The method of claim 7, wherein the link teardown procedure 
further comprises the steps of: 

triggering a route mamtenance procedure at the first node to find an 
alternative path prior to sending the link teardown request message; and 
10 sending the link teardown request message to the second node if the an 

alternative path is found. 

13. The method of claim 1, wherein the predetermined time period is 
set based upon an amount of traffic that would be affected by the reconfiguration, 

14. The method of claim 1 , wherein if the link setup procedure, role 
15 switch procedure or the Imk teardown procedure fails, performing the step of: 

setting a backoff tuner to a minimum value between two times a current 
value of the backoff timer and a maximum backoff timer value. 



15 . A network comprising: 
a first node includmg a first table; 
20 a second node includmg a second table; and 

a first communications Imk connecting the first node and the second node, 
wherein the first node periodically detennines whether to initiate 
reconfiguration of the network based upon information stored in the first table and 
the second node periodically determines whether to initiate reconfiguration of the 
25 network based upon information stored m the second table. 
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16. The network of claim 15, further comprising: 
a third node comprising a third table; and 

a second communications link connecting the third node to the second 

node, 

5 wherein the third node periodically determines whether to initiate 

reconfiguration of the network based upon information stored in the third table. 

17. The network of claim 16, wherein the second node periodically 
determines, based upon an amount of traffic forwarded by the second node 

between the first and third nodes, whether to initiate a link setup procedure 
1 0 between the first and third nodes . 

18 . The network of claim 17, wherein the link configuration procedure 
establishes a third communications link between the first node and the third node. 



19. The network of claim 15, wherein the first node, based upon an 
amount of traffic handled by the first node and an amount of capacity that the first 

15 node esthnates it will be able to gain by a master-slave switch, initiates a master- 
slave switch procedure with the second node. 

20. The network of claim 15, wherein the first node, based upon an 
amount of capacity that the first node estimates it will be able to gain as the result 
of a link teardown and based upon an amount of capacity that the network will 

20 gain as a result of the link teardown, initiates a Inak teardown procedure with the 
second node. 

21 . The network of claim 15, wherein first table contaiins information 
about traffic that the first node is forwarding and information about traffic to and 
from nodes which are neighbors of the first node, and titie second table contams 
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information about traffic fliat the second node is forwarding and information about 
traffic to and from nodes which are neighbors of the second node. 
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